Network congestion can occur when too much data is sent through a particular link or node of a network. Such congestion may negatively affect the quality of service provided by the network. For example, it may cause queuing delays, packet losses, and blocked connections. Therefore, it is desirable to make sure that the amount of traffic passing through each node of the network does not exceed what the node can handle.
A typical scenario of network congestion is illustrated in FIG. 1. As illustrated, the network includes two servers A and B 100, 102, a switch 104, and two disks T1 and T2 108, 110. The number of devices shown in FIG. 1 is limited for illustration purposes only. Additional servers, switches, disks, and other types of devices may be connected to the network. Both servers A and B 100, 102 and both disks T1 and T2 108, 110 are connected to the switch 104 by 10 Gbps Ethernet cables. This setup allows the servers A and B 100, 102 to communicate with each of the disks T1 and T2 108, 110 via the switch 104. In this exemplary network, when servers A and B 100, 102 simultaneously attempt to send 10 gigabytes of data over the Ethernet cable to disk T1 108, the switch 104 may experience congestion because there will be a total of 20 gigabytes of incoming data from the two servers A and B 100, 102 while the switch only has a 10 gigabyte outgoing connection to disk T1 108. As a result, not all packets received by the switch 104 can be forwarded to disk T1 108 right away. Some of the packets may have to be temporarily stored in a buffer of the switch before they can be forwarded to disk T1 108. If there is not enough space in the buffer, the switch 104 may be forced to drop some of the packets without forwarding them to the destination disk T1 108. In certain types of networks, depending on the network protocol used, dropping packets may potentially cause the whole data flow to be terminated and all packets to be retransmitted. This may result in significant performance degradation and network delay, particularly when the network is handling a large data transfer.
To reduce the negative effects of congestion on a network, one solution is to design the switch 104 so that it can notify the source of a transmission (e.g., servers A and B 100, 102 in FIG. 1), when congestion is detected, to enable the source to reduce its output before the switch 104 runs out of buffer space. This would guarantee efficient system behavior by preventing packets from being dropped and, at the same time, generating a predictable performance for applications running on servers A and B 100, 102.
Some of the current network protocols have built-in mechanisms to respond to congestion. For example, if the TCP protocol is used by the network of FIG. 1, the servers A and B 100, 102 may reduce their outgoing bandwidth by half when they detect that the downstream switch 104 is experiencing congestion and dropping packets. After their output is cut in half in response to the congestion, the servers 100, 102 may then gradually increase output based on existing congestion control mechanisms, such as TCP congestion control. In response to the second notice, the servers 100, 102 again would reduce their output by half. This process may be repeated until no further congestion notices are received or all packets are successfully transmitted. However, this may not be the optimal solution for the applications running on the servers 100, 102 because there may be bandwidth not utilized when both servers 100, 102 reduce output by half.
Therefore, it is desirable to have a better way for the switch (or any other target device of a network communication) to notify the source about downstream congestion in the network so that the source can reduce its output by halting the transmission of packets. Other known solutions for preventing congestion in a network involve the use of rate limiters to control individual flows from the reaction points (i.e., the source of the transmission) that are causing congestion. This usually requires that the congested node send a backwards congestion notification (BCN) to the source of the transmission (e.g., the servers in FIG. 1). After receiving the BCN message, the source may provide relief by rate limiting the outgoing packets to reduce congestion. (See U.S. Patent Application No. 2006/0203730 to Zur). One example of rate limiters on the transmission source is introduced in U.S. Pat. No. 7,106,696 to Lim et al.
However, none of the existing rate limiters provide software and firmware adjustable controls over the congestion by selectively rate limiting outbound traffic on a packet level. In addition, none of the existing rate limiters selectively limit packets based on the flows, virtual machines, and blade servers associated with the outgoing packets.